Skip to content

Conversation

@stanislav-tkach
Copy link
Member

@stanislav-tkach stanislav-tkach commented Jan 25, 2025

Description

  • Add report_duplicated_key and report_missing_keys functions to the cbork-utils crate.

Description of Changes

It is rather common pattern in the Decode trait implementation to check for report duplicated keys and check presence of the required ones. For example in CIP-36 decoding and CIP-509 decoding. I'm not sure if cbork-utils is the best place for these functions, but it would be nice to reuse them instead of having several almost identical implementations.

Please confirm the following checks

  • My code follows the style guidelines of this project
  • I have performed a self-review of my code
  • I have commented my code, particularly in hard-to-understand areas
  • I have made corresponding changes to the documentation
  • My changes generate no new warnings
  • I have added tests that prove my fix is effective or that my feature works
  • New and existing unit tests pass locally with my changes
  • Any dependent changes have been merged and published in downstream module

@stanislav-tkach stanislav-tkach changed the title feat(rust/cbork-utils): Add report_duplicated_key and report_missing_keys to the cbork-utils crate feat(rust/cbork-utils): Add report_duplicated_key and report_missing_keys functions to the cbork-utils crate Jan 25, 2025
@github-actions
Copy link
Contributor

Test Report | ${\color{lightgreen}Pass: 272/272}$ | ${\color{red}Fail: 0/272}$ |

@stanislav-tkach stanislav-tkach changed the title feat(rust/cbork-utils): Add report_duplicated_key and report_missing_keys functions to the cbork-utils crate feat(rust/cbork): Add report_duplicated_key and report_missing_keys functions to the cbork-utils crate Jan 25, 2025
@bkioshn
Copy link
Contributor

bkioshn commented Jan 27, 2025

Agree that it is better to use them, but feel like it is better to move it to catalyst-types.
Even though the name is types but there are some conversion function there, so I think it is okay to move it there.

@stanislav-tkach
Copy link
Member Author

@bkioshn I agree with you reasoning. Additionally it won't introduce an additional dependency to `cbork-utils.

@stanislav-tkach
Copy link
Member Author

Closed in favor of #180.

@stanislav-tkach stanislav-tkach deleted the cbork-problem-report-utils branch January 27, 2025 10:05
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants